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SOFTWARE DISTRIBUTION SYSTEM 
Field of the Invention 

This invention relates to multiprocessor computer 
5 systems and in particular to the distribution of updated 
versions of software to particular processors within 
such systems. 

Background of the Invention 

Traditionally^ there have been two basic hardware 
10 configurations employed in the design of computer 
systems for multiple users. The first of these 
configurations includes a central processing unit, 
sometimes referred to as a "mainframe, connected to a 
plurality of user input/ output terminals. Each user 
15 input/output terminal is typically comprised of a 
keyboard for data entry and a cathode-ray tube or 
printer for data display. 

The other of these two basic hardwai^e configurations is 
comprised of a number of individual processor units or 

20 "nodes", one for each user or small group of users, 

connected in a network. The network, which can serve to 
connect nodes separated by large geographic distances, 
allows the sharing of software and data among users. 
Each node in the system may be connected to one or more 

25 input/output terminals* In networks such as this, there 
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may also be an additional node or nodes not dedicated to 
a particular user which may control one or more 
centralized databases for storing and retrieving data 
and software for the various users whose nodes are 
5 connected to the network. Furthermore, an additional 
node aay be used by computer system overseers or 
"operator" personnel who monitor and control the 
operation of the network. Typically, such additional 
nodes also have input/output terminals connected to 
10 them. This -networked" system of multiple nodes has 
gained wide acceptwce today. 

The acceptance of the multinode networked system is 
generally based upon the proliferation of "micro" or 
"personal" computers in the business and technical 

15 fields. These computers provide each user of a 

multinode system with dedicated computer power necessary 
to perform his business or technical functions, with a 
micro-computer node dedicated to his use, a user can 
perform his business or technical tasks more efficiently 

20 and easily, m addition to dedicated micro-computers, 
such systems often include mainframes for, among othe^ 
things, database-related processing, and mini- or 
super-mini-computers to perform real-time processing. 

The software employed in computer systems, whether of 
the first or second type hardware configuration 
described above, can generally be classified into one of 
two main categories. First, there is the so-called 
"operating systems software." Operating systems 
software is concerned with controlling the basic 
operation of a computer processor and/or system for 
input/output tasks, as well as memory-access tasks, in 
addition, operating systems software controls the 
execution of other computer programs. These other 
computer programs comprise the other main category of 
35 software, termed "applications software." Applications 



25 



30 
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software typically performs a specialized technical or 
business-related fiinction with which a user is 
concerned. 

Softwcure, whether of the operating systems or 
5 application variety, is often comprised of many 

interrelated constituent computer programs. Constituent 
programs generally form a "software hierarchy" with 
"executive" programs controlling or directing the 
operation of "subordinate" programs within the 

10 hierarchy. The rcmge of hierarchical structures for 

software is almost limitless. For example, there can be 
one or more "executive" programs, each controlling the 
execution of (or "calling") one or more subordinate 
programs. These subordinate programs or "subroutines" 

15 can call subordinate programs of their own, and so on. 
There may be many levels of sxibordinated constituent 
programs in a hierarchy. Generally, the lower the level 
of a program in a hierarchy, the more elemental its task 
or function. Those progrsuas which call one or more 

20 subordinate programs generally perform more complex 

tasks which are, in effect, amalgams of more elemental 
tasks performed by called siibordinate programs. With 
applications software, there is often more than one 
hierarchy of programs associated with the application. 

25 Applications software can be thought of as accomplishing 
a business or technical "function." A function, in 
turn, is comprised of one or more "processes." It is a 
"process" which is comprised of one or more hierarchies 
of programs. Because a program hierarchy is generally 

30 responsible for performing a certain task, a process can 
therefore be viewed as a logical subdivision of a 
business or technical function. 

In the multinode computer system context, an application 
may be executed on more than one node. When constituent 
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processas of an appllca-tlon execu-te in a pairsaiel 
fashion on separate nodes in the system f i.e. . 
simultaneous execution of parts of the application on 
multiple nodes) , the application is said to be processed 
5 in a ^•distributed" fashion. When processes of an 
application execute in a serial fashion on separate 
nodes in the system ( i.e. , execution such that a given 
node is the only node in the system executing an 
application process at a given time) , the application is 
10 said to be processed in a "cooperative" fashion. 

In many multinode systems, some of the nodes or groups 
of nodes are intended to execute identical processes or 
groups of processes. Por example, eLn airline may find 
it desirable to have identical software executed on the 

15 various nodes which run its application for taking 
airline reservations. Identical software may be 
necessary so that the users of the system, the airline 
reservation clerks or ticket agents, can provide the 
same services to prospective passengers regardless of 

20 which clerk or ticket agent is approached by the 
prospective passenger. 



Often, however, such systems have other nodes which 
execute distinct processes for distinct purposes. For 
example, an airline's applications software may not only 

25 have a ticketing/reseryation process, but also a process 
loseful for tracking baggage, in both the distributed 
and cooperative processing contexts, specific nodes in 
the airline's mxiltinode system may perform only the 
baggage tracking process. Furthermore, it may be 

30 useful for some nodes within a system to execute 

software which performs more than one process, such 
nodes would therefore execute the necessary groups of 
processes. In the above example, these nodes would 
execute both the ticketing and baggage tracking 

35 processes. 
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As s1:at:ed above ^ each application is usually nade up of 
many individual processes comprised of hierarchies of 
compu1:er programs. Some of the individual processes 
within a function and some of the individual programs 
5 within a process may be shared eunong several functions 
and processes, respectively. This overlap most often 
occurs with lower level processes and programs within 
software hierarchies. For exsmple, both ticket 
reservation and baggage tracking functions may require a 
10 process or program to write information to a database 

for subsequent retrieval. Such a process or program may 
not be dependent on the type of data stored. Thus, both 
functions may use the scune process or program to support 
the accomplishment of their tasks. 

15 Often, applications software may require alteration 

because of the need to correct errors in program code or 
the need to include enhancements to a particular process 
within an application. However, because many progrcuns 
share data resources, many processes share programs, and 

20 many nodes share processes, a programmer making a 

needed alteration to a process' constituent progreun or 
programs is likely ^lnaware of (1) all programs and 
processes he is affecting by his alteration, and (2) 
which nodes in the multiprocessor system will require a 
25 copy of his updated or altered software program or 
programs . 

Thus, there is a need to determine all programs and 
processes affected by changes to individual programs so 
that particular nodes which execute the affected 

30 processes can be identified. In addition, there is the 
need to physically distribute the updated versions of 
programs to the individual nodes of the network which 
execute the affected processes. In the past, these 
needs were accomplished by cin individual or individuals 

35 who manually determined all programs and nodes affected 

BNSCCCID: <WO___9ioe542Al_L> 



*° PCr/USM/0701. 



-6- 



10 



15 



by program alterations and the identity of the nodes in 
the system which executed the affected processes. 
Furthermore, such individuals had to physically 
transport updated versions of the programs generally 
stored on a computer disk (typically a "floppy disk") or 
tape, to the individual nodes for loading into 
associated memories. Even for small networks, where 
nodes are located in relatively close proximity to each 
other, the determination of affected programs and 
processes and the installation of updated versions of 
processes can be cumbersome at best. But, with larger, 
more complex networks executing many applications having 
laany functions and processes, and with the possibility 
of large geographic distances between nodes in such 
networks, the difficulties associated with determining 
all affected processes and the logistical problems 
associated with the physical distribution of updated 
software can be highly burdensome, if not impossible as 
a practical matter. 

20 STjmmarv of the Inven-hinr. 

These problems are solved by the present invention which 
is a software distribution system (SDS) for distributing 
software programs to particular nodes in a multinode 
system. One aspect of the SDS is a relational database 
Which contains information which relates an application 
to its associated data entities and its associated 
processes, and which relates processes to individual 
nodes in a multinode computer network, whether of the 
distributed or cooperative type. Another aspect of SDS 
further provides a processing means (or node) , 
associated with the database, for determining each 
program and process affected by an alteration to a 
program and the identity of all nodes in the network 
which execute the affected processes. SDS also provides 
a warehouse database for storing software to be 
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dis'tribu'ted, and a dis'tribution cheumel for delivering 
any altered progreuns to identified nodes within the 

* 

multinode network. 

The database aspect of SDS is built according to an 
5 entity-relationsbip model which defines certain logical 
entities cmd relationships among such entities. These 
entities specify the elements of a multinode system^ 
including its hardware, software and data. The entities 
provided by the datsdaase portion of SDS include 

10 "Workstations" (which are nodes and associated 

input/ output devices), "Processes," "Programs," "Data," 
and "Releases" (which are logical units of work to be 
distributed by SDS) . The relationships among entities 
are also defined by the database of SDS and include a 

15 "Workstation to Process" relationship, associating a 

node to a Process to which it has access; a "Release to 
Process" relationship, associating a given Release with 
a given Process; a "Release to Progrsun" relationship, 
associating a given Prograun with a given Release; and a 

20 "Release to Data" relationship, associating a given 
Release with given Data. 

The processing means aspect of SDS using the above 
described database operates to determine all entities 
which are affected by an update or change to a given 
25 progreun or data. Either the same or another processing 
means controls the transmission of identified software 
or data from the warehouse dateibase to the appropriate 
Workstations for installation thereon. 

Brief Description of the Drawings 

30 Figure 1 is an illustration of a three-tiered computer 
system. 

Figure 2 is an illustration of a two-tiered computer 

BNSDOCID: <W0 9108542A1_L> 



wo 91/08542 



PCr/US90/0701I 



-8- 

system. 



Figure 3a is a diagramnatic representation of an 
entity-relationship model according to the present 
invention. 

5 Figure 3b is a diagrammatic representation of an 
entity-relationship model according to the present 
invention. 

Figure 3c is a diagrammatic representation of a portion 
of the contents of a database constructed according to 
10 an entity-relationship model illustrated in Figure 3a. 

Figure 3d is a diagrammatic representation of a portion 
of the contents of a database constructed according to 
an entity-relationship model illustrated in Figure 3b. 

Figures 3e and 3f are diagramatic representations of 
15 portions of databases constructed according to entity- 
relationship models illustrated in Figures 3a and 3b. 

Figure 4 is a diagrammatic representation of the entity 
and relationship instances associated with a release, as 
well as the migration path of modified entity instances 
20 being distributed. 

Detailed Descrip tion of the Invention 

Typical hardware configurations for computer systems 
employing the present software distribution system 
invention (SDS) are depicted in Figures 1 and 2. Figure 
25 1 depicts a "three tiered" computer system, so named for 
its three levels of computer processors or "hardware 
platforms." a "three tiered" system can be comprised, 
for example, of a mainframe computer 1, a mini- or 
super-mini-computer 2, and micro-computers and their 



BNSOOCIO: <WO_910e542A1 



PCT/US90/07011 



-9- 

associated input/ output devices, collectively referred 
to as "workstations" 3. 

Typical processors preferred for each of these tiers eure 
the IBM mainframe sold under the trademark "Model 3090", 
5 running the IBM MVS/XA operating system; the Stratus 
mini-computer sold under the trademark "Model XA2000", 
running the Stratus Computer, Inc. VOS operating system, 
and the IBM micro- computer sold under the trademark 
"PS2", executing the Microsoft Corporation operating 

10 system sold under the trademaurk "MS-DOS*" (For fxirther 
information on these processors or their operating 
systems, the reader is referred to the "IBM System/370 
Bibliography", document number GC20-0001; the "IBM 
Technical Directory", document number 6024448; and 

15 "Introduction to VOS", by Stratus Computer, Inc., 
document number ROOOl.) 

Each of these processors and workstations is a node in 
the network. The mainfrsune computer 1 is connected to 
amd performs all processing associated with a database 

20 5, referred to as the "Repository." The Repository 5 is 
used to store a description of an application in terms 
of an SDS Entity-Relationship Model discussed below. 
The mainframe 1 may also be connected to a micro- 
computer with an input/output (I/O) device 6 ( i*e. , a 

25 workstation) , or simply an input/ output device. In 

either case, the purpose of this connection is to allow 
a human to access the Repository 5, as well as control 
mainframe 1 processing. The mini-computer 2 is 
connected to the mainframe 1 and to a database of its 

30 own, referred to as the "warehouse" 4. The warehouse 4 
is used to store all versions of all software programs 
and data which comprise a given application. Like the 
mainframe 1, the mini-computer 2 may also have a 
workstation or I/O device 6 for human access to the 

35 warehouse 4 and to control mini-computer 2 processing. 
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The mini-computer 2 is further connected to a one or 
more workstations 3. The computer system (or network) 
can have as many workstations 3 as would be desired to 
support user access to given applications software. 

5 Figure 2 depicts a "two tiered" computer system, so 

named for its two distinct levels of hardware platforms. 
Unlilce the three tiered system, the two tiered system 
includes only one platform in addition to its 
workstations 3. Typically, the two tiered system 

10 includes a mainframe 7, performing the work of both the 
mainframe l and mini-computer 2 of the three tiered 
system depicted in Figure 1. The mainframe 7 of the two 
tiered computer system is connected to both a Repository 
database 5 and a Warehouse database 4, as well as a 

15 workstation or I/O device 6 for database access and 
processor control. As mentioned, the mainframe 7 is 
connected to a network of workstations 3. However, a 
processor of another type could substitute for the 
mainframe processor 7 in the two tiered system, 
20 depending on specific through-put requirements and 

equipment availability. As is the case with the three 
tiered system, the processor and workstations of the two 
tiered system are nodes in the network. 

Regardless of whether the computer system of Figure 1 or 
25 Figure 2 is employed for the distribution and execution 
of applications software, the software and data to be 
distributed is maintained in the warehouse 4 . This 
software and data may be stored in executable form or in 
a source code format. The information necessary to 
30 properly distribute such software is maintained by 
Repository 5, with the mainframes l, 7 executing 
software necessary to determine what software must be 
distributed. Generally, the nodes which will receive 
software distributed by SDS sure the workstations 3. 
35 However, such workstations 3 could be replaced, by other 
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nodes of t:he mainframe or mini-computer variety, 
themselves connected to other nodes in a network. Thus, 
the SDS is not limited to the distribution of softw£ure 
solely to micro-computer-based workstations. Rather, 
5 SOS is suitable to distribute software and data to any 
node in the network. However, for clarity of 
explsination, this description will refer to all nodes in 
a system which are to receive distributed software and 
data as Worlcstations • 

10 The SDS Entity-Relationship Model 

As indicated above, all information necessary to 
properly distribute updated portions of applications 
software f i.e. , a Release) to the appropriate 
Workstations 3 in the network is maintained by the 
15 Repository 5, which is a special -ptirpose relational 
database. 

A "relational datsODase" is a term used to described a 
computer program which carries out the storage, 
searching emd retrieval of data on a mass storage 

20 medixam, such as a disk storage system. "Relational 

database" is also used to describe information stored on 
a disk storage system by a relational datcibase program. 
A relational database progrsim stores, searches and 
retrieves data according to specific commands from the 

25 database user. That is, with a relational database, a 
user specifies the data to be stored, the seeorching (or 
"traversing") of the database to be performed, eoid what 
is to be retrieved by the database program. Relational 
database programs are well known and are available 

30 commercially. For purposes of a preferred embodiment of 
this invention, it is preferred that the IBM relational 
database sold under the trademark "DB2" be employed. 
(For more background information on DB2, the reader is 
referred to the following IBM publications which are 
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hereby incorporated by reference: "IBM DATABASE 2 
Introduction to SQLn (document number GC26-4082) ; "IBM 
DATABASE 2 Reference" (document number SC26-4078); 
"OS/VS2 TSO command Language Reference" ( document nunber 
GC28-0646) ; "TSO Extensions Command Language Reference" 
(document number SC28-1307) ? "Interactive System 
Productivity Facility/Program Development Facility for 
MVS: Program Reference" (document nxanber SC34-2089) ; 
"interactive System Productivity Facility/Program 
Development Facility for MVS: Dialog Management 
Services" (doctament number SC34-2137) ; and "DB2 
Application Programming Guide for TSO and Batch Users.") 

The Repository 5 maintains information on all elements 
of a computer system which are necessary for software 
distribution, as well as all necessary interaction among 
computer system elements. These elements (or 
"entities") and their interactions (or "relationships") 
are defined generally by an SDS Entity-Relationship 
Model, Which is the basis of information organization in 
the repository 5. The SDS Entity-Relationship Model 
thus provides the basis for all commands to a relational 
database program. The Model supplies the intelligence 
needed to create and maintain the Repository 5 via the 
relational database program, which is only a tool^ in the 
25 context of the present invention. 



15 



20 



30 



The "entities" of the Model represent something real er 
abstract about which information is recorded in the 
Repository 5. This information is organized into a set 
of characteristics known as "attributes." Entities 
which share a common set of attributes are grouped into 
classes called "entity types." An "entity instance" is 
a specific occurrence of an entity type and is described 
by a set of specific attributes. 

The "relationships" of the SDS Entity-Relationship Model 
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specify em assocla'tion between entities. Zjike enti'ties, 
relationships sure described by their attributes. 
Relationships with common attributes eltb referred to as 
''relationship types," while a "relationship instemce" is 
5 a specific occurrence of a relationship type and is 
described by a set of specific attribu1:es. 

The SDS Entity-Relationship Model therefore provides a 
representation of "the overall logical structure and 
elements of software generally in terms of specific 
10 entity and relationship instances definable through the 
Model • 

The entity types of the SDS Entity-Relationship Model 
are as follows: 

- "Workstations," which describe the 

15 physical workstations to which software 

must ultimately be distributed; 

- "Workstation Groups" which describe 
logical groupings of workstations; 

- "Release, " which describes the logical 
20 unit of work to be distributed by SDS; 

- "Function," which describes a given 
application software package; 

- "Process," which describes a logical 
subdivision of a function; 

25 - "ProgrEua," which describes m individual 

software routine, either executive or 
sxibordinate , which forms a portion of a 
process ; 
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- "Data Entity," which describes a 
collection of data values which are 
necessary for the operation of a program; 

- "Value," which describes a single static 
5 data item literally (either in integer, 

decimal or character formats) • 

The attributes associated with these entity types 
include an attribute which identifies discrete instances 
of such entities. Thus, the Repository 5 contains 
10 information identifying each Function, and each 

constituent Process, Program, and Data Entity, as well 
as each Workstation Group and Workstation, comprising 
the hardware and software of a given computer system. 

In addition to an identifier attribute, certain entity 
15 types have associated with them additional attributes. 
Fiinction attributes also include an Application ID 
attribute, which specifies the Applications Software in 
which a given Fxinction instance is used. Program 
attributes also include an Execution Environment 
20 attribute, which specifies the hardware platform on 
which a given Progrem instamce executes. Value 
attributes include the numerical value of a given datum. 

In addition to entities and their attributes, SDS 
defines certain relationships among entities. These 

25 relationships are also incorporated in the SDS Entity- 
Relationship Model depicted in Figure 3a. The first of 
these is the '"Refines" relationship 42. Refines 42 is 
used to describe the decomposition of Functions 41 into 
Processes 43. The highest level or executive Process is 

30 known as a "Root" Process (so known because other 

Processes brsuich out from it) . Refines 42 ' is also used 
to describe the decomposition of a Root Process into 
intermediate and lowest level Processes, known as "Node" 
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and "Leaf" Processes, respectively. When iised to 
describe the decomposition of Ftinctions 41 into 
Processes 43, Refines 42 represents the first step in 
the step-wise refinement of Functions 41 into executsddle 
5 Prograuns. 46. When used to describe the decosposition of 
a highest or higher level Process 43 into a lover or 
lowest level Process 43, Refines 42' represents a 
further step in the same step-wise refinement. 

The attributes associated with the Refines 42, 42' 
10 relationship include the identification of the 

"participants" in the relationship. Specifically, there 
is the "First Participant" attribute, which identifies 
the Fiinct ion/Process instances being refined, and there 
is the "Second Participant" attribute, which identifies 
15 the Process instance immediately subordinate to the 
First Peurticipsmt . 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
"Defines" 44. The Defines relationship 44 is used to 
describe the relation between a Process 43 and a Program 
46. Specifically, the relationship connects an instance 
of the lowest level Process 43 (Leaf Process) to a 
Program 46. Generally, the Program 46 specified by the 
Defines relationship 44 is the highest level Progrcun in 
the Leaf Process, and is known as a "Root" Program. 
Defines 44 represents yet another step in the refinement 
of Functions 41 into Programs 46. 

The attributes associated with the Defines relationship 
44 include the identification of participants in the 
30 relationship. The First Participant attribute 

identifies the Leaf Process instance being defined, and 
the Second Participant attribute identifies the highest 
level or Root Program instance of the Leaf Process. 



20 
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Another of the rela-blonships defined by SDS and 
incorpora-ted into the SDS Entity-Relationship Model is 
"Uses" 45. The Uses relationship 45 describes the 
relation between one Program 46 and another. Uses 45 
5 relates a higher or highest (Root) level Program to a 
subordinate Program. It provides for the further step- 
wise refinement of Functions 41 into Programs 46. 

The attributes associated with the Uses relationship 45 
include the identification of the participemts in the 
10 relationship. The First Participeuit attribute 

identifies the highest or higher level Program instemce 
using the Second Participant attribute, the lower level 
Program instemce. 

A further relationship defined by SDS and incorporated 
15 into the SDS Entity-Relationship Model is "Refers" 47. 
Refers 47 is used to describe the relationship between a 
Program 46 and an external Data Entity 48. A Program 46 
may Refer 47 to a Data Entity 48 by making a local 
declcuration statement within the Program 46 to the Data 
20 Entity 48. 

The attributes associated with the Refers relationship 
47 include the identification of the participants in the 
relationship. The First Psurticipant identifies the 
Program instance requiring a reference to the Data 
25 Entity instance. The Second Participant is the common 
identifier name for a collection of data Values, i.e. , 
the Data Entity instance. 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
30 "Members" 49. The Members relationship associates a 
Data Entity 48 to its individual meinber Values 50. 

The attributes associated with the Manbers relationship 
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49 include the identification of the participants in the 
relationship and a Symbol Name for the Second 
Participant. The First Participant attribute identifies 
the common identifier name for the group of data Values 
5 ( i,e. , the Data Entity instance) . The Second 

Participant attribute is an individual Value of data. 
The Symbol Name attribute is a symbolic name which can 
be used to refer to the Value of data identified by the 
Second Participant, without using the Value itself. 

10 Another of the relationships defined by SDS and 

incorporated into the SDS Entity-Relationship Model is 
"Workstation Group To Process" 51. This relationship 
associates a Workstation Group 52 to the Process 43 to 
which it has access. 

15 The attributes associated with the Workstation Group to 
Process relationship 51 include the identification of 
the Participants in the relationship. The First 
Participant attribute identifies a Process instance. 
The Second Participeuit attribute identifies the 

20 Workstation Group instance having access to the First 
Participant. 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
"Workstation To Workstation Group" 53. The Workstation 
25 To Workstation Group relationship 53 defines the 

association between a Workstation 54 and the Workstation 
Group 52 to which it belongs. 

The attributes associated with the Workstation To 
Workstation Group relationship 53 include the 
30 identification of the participants in the relationship. 
The First Participant attribute identifies the 
particular Workstation Group instance in question. The 
Second Participant attribute identifies the Workstation 
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instance belonging to the First Participant* 

Shoxild a given applications software processing system 
not employ identifiable groups of workstations, or, 
should it be undesirable to have identif ied^le 
5 workstation groups, the Repository 5 would not need the 
entity of Workstation Groups, nor the specific 
relationships of Workstation Group to Process or 
Workstation to Workstation Group. Rather, all that the 
Entity-Relationship Model of the Repository 5 would 
10 maintain would be a "Workstation to Process" 
relationship . 

The attributes associated with the Workstation to 
Process relationship include the participsmts in the 
relationship. The First Participant attribute 
15 identifies a Process instance. The Second Psirticipant 
attribute identifies the Workstation instance having 
access to the First Participant. 

Another of the relationships defined by SDS smd 
incorporated into the SDS Entity-Relationship Model and 
20 referenced in Figure 5 is "Release To Process" 55. The 
Release To Process relationship 55 associates a Release 
20 with a Process 43 affected by the Release 20. 

The attributes associated with the Release To Process 
relationship 55 include the participants in the 
25 relationship. The First Participant attribute 

identifies the Release instemce in question. The Second 
Participant attribute identifies a Process instance 
affected by the First Participant. 

Yet another of the relationships defined by SDS and 
30 incorporated into the SDS Entity-Relationship Model is 
"Release To Program" 56* The Release To Program 
relationship 56 associates a Program 18 to be 
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distributed by SDS in a particxilar Release with the 
Release 20 itself. 

The attributes associated with the Release To Program 
relationship 56 include the identification of the 
5 participants in the relationship. The First Participant 
attribute identifies a Release instance. The Second 
Participant attribute identifies a given Program 
instance to be distributed by SDS by the particular 
Release instsmce identified by the First Participant • 
10 Other attributes of the Release To Program relationship 

56 include a Program's Logical File Name. A Logical 
File Name is a function of both a Physical File Name 
(discussed below) and a Release name. It allows 
different Releases to refer to different versions of the 

15 same entity. Other attributes include a Physical File 
Name and a Path Name. A Physical File Name refers to a 
block of executable code, and is an input to the Logical 
File Name generation process. A Physical File Ncune will 
usually be the same as the name of the entity ( i.e. , the 

20 identification attribute of an entity instance) , but can 
further include extensions should a given Program be 
comprised of more than one file of executcdDle code. A 
Path Name refers to a high level portion of a disk 
address at a particular workstation where software will 

25 be stored once distributed and installed. 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
"Release To Data" 57. The Release To Data relationship 

57 is used to identify a Data Entity 19 to be 

30 distributed by SDS in a particular Release with the 
Release 20 itself. 

The attributes associated with the Release To Data 
relationship 57 include the identification of the 
participemts in the relationship. The First Participamt 
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attribute identifies the Release instatnce. The Second 
Participemt attribute identifies a Data Entity instance 
to be distributed by SDS for the particular Release 
instance identified by the First Participant. Other 
5 attributes of the Release to Data relationship include a 
Data entity's Logical File Name which, as discussed 
above, is a ftmction of both a Physical File Name and a 
Release Name. As with the Release to Program 
relationship 56, attributes of the Release to Data 
10 relationship 57 include a Data Entity's Physical File 
Name and Path Name. 

Depending upon the overall nature of the computer system 
in which SDS is employed, it may be useful to define 
additional entities and relationships tailored to the 
15 system. For example, if there are particular or special 
types of programs defined for use in a certain computer 
system, entity types corresponding to these program 
types can be adopted for xase in the Repository 5. 

Special Entities and Relationships 
20 Defined by the SDS Entity-Relationship Model 

Often in various software applications in the business 
and technical fields, there are special program, I/O, 
and data related entities and relationships which serve 
to enhance the operation and efficiency of software. 

25 For instance, in the field of Computer-Aided Software 
Engineering (CASE) , which concerns specialized computer 
software which aids in the design smd/or coding of 
applications programs, special program types, data axid 
interactions among programs and data exist. Therefore, 

30 where CASE and other special software is concerned, the 
SDS Entity-Relationship Model takes account of special 
program types, data and interactions by further 
providing SDS entity emd relationship types tailored for 
use with this special software. 
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The first of these entities is the "Rule." A Riile is a 
special type of Program vhich provides the procedxiral 
specifications of the logic for a portion of a Process. 
In addition, a Rule can control, among other things, the 
5 execution of other Rules. Rules themselves are 

generally specified in a high level language referred to 
as "Rules language." Rules language is typically not 
executable source code, but rather "pseudocode" which in 
some ways resembles English and which can be readily 

10 translated into one of the msmy available computer 

source code languages. Rules language is based on the 
principles of structured design and programming. Thus, 
with the Rules language, a designer of applications 
software can design Rules pseudocode to perform such 

15 structured constructs as "Do While," "Do Until," and 
"If, Then, Else," for example. Rules and the Rules 
language make it generally possible for an applications 
software designer to design software without concern for 
the specific language which may be required by a 

20 specific processor node. This capability can be 
particularly useful in cooperative and distributed 
processing systems where cm application may be executing . 
on several disparate nodes which employ various source 
code compilers. 

25 The attributes associated with the Rule entity type 

include an attribute for the identification of discrete 
instamces of Rules, as well as an attribute specifying 
execution environment for the Rule instemce. 

A second entity defined for CASE {or other special) 
30 softwcure is the "Component." A Component is a block of 
computer instructions written in a source code 
prograunming language. Components are used to perform 
the fxinctions not handled by Rules. 
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The attributes associated with Components include an 
attribute for the identification of discrete instances 
of Components, eui attribute specifying execution 
environment for the Component instance, and an attribute 
5 specifying the sotxrce code Icmguage in which a Component 
instemce is written. 

The next of these entities is the "Window." Windows are 
a type of Progreim which def dLne the man-machine 
interface. They specify what data is to be accepted 

10 from a user, how it is to be displayed, and how it is to 
be accepted. . In designing an application or portion 
thereof for execution on an "IBM PC," it is preferred 
that the Microsoft Corporation's Window program, sold 
under the trademark "MICROSOFT WINDOWS," be used. (For 

15 more background information on MICROSOFT WINDOWS^ the 
reader is referred to the following Microsoft 
Corporation publications which are hereby incorporated 
by reference: "Microsoft Windows Programmer's Utility 
Guide" ; "Microsoft Windows Application Style Guide" ; 

20 "Microsoft Windows Programmer's Reference"; and 
"Microsoft Windows Quick Reference.") 

The attributes associated with Windows include an 
attribute identifying discrete Window instances. 

For most systems, the only nodes capable of executing 
25 Window entities are the Workstations, since they will 
usually be the only platforms which comprise a cathode- 
ray tube display in addition to a processor. As such, 
there is usually no need for an attribute describing the 
execution environment of the Window. However, should a 
30 particular computer system be configured to include 
cathode-ray tube displays connected to mainframe or 
mini-computer nodes, the SDS Entity-Relationship Model 
can be adapted to include for the Window entity the 
additional attribute of execution environment. 



wo 91/08542 



PCT/US90/07011 



-23- 

A fxirther of these entities is a "View." A View is a 
logical collection of data elements (or "Fields** as 
described below) • A view can also comprise other Views . 
Essentially, a View is a multiplicity of data variables 
5 (or Fields -* see below) and is particularly useful for 
defining the data interface between one progreun and 
another or from a system user to a program. The former 
type is referred to as a ''Module View" and the latter is 
referred to as a "Window View". 

10 The attributes associated with Views include cin 
identification attribute specifying discrete View 
instances . 

Another of these entities is a Field. Fields describe 
the basic data elements that comprise a business or 
15 technical data resource. A Field stores all information 
about data elements independent of the environment in 
which the data is actually stored. 

The attributes associated with Fields include an 
identification attribute, for specifying discrete Field 
20 instemces; a Field Format attribute, for describing the 
format in which data is stored in memory ( e.cy. , integer, 
decimal, character, etc.); and a Field Length attribute, 
for specifying the size (or length) of a Field. 

For applications designed with certain CASE software, 
25 the higher level entities and relationships still apply 
(see Figure 3b) • That is, the Function 41 and Process 
43 entities, as well as the Refines 42, 42' and Defines 
44' relationships, are a part of the SDS Entity- 
Relationship Model and are used to described a software 
30 application in the Repository 5. The only difference is 
with respect to the Defines relationship 44 ' , which in 
the CASE context is used to describe the relation 
between a Process 4 3 and Riile 60. 
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The attributes of the Refines 42, 42' and Defines 44' 
relationships sure the same as defined previously. 

The Uses relationship defined previotasly to describe the 
relationship between Programs is used dLn the CASE 
5 context to describe the relationship between two Rules 
(61), a Rule and a component (61'), amd two Components 
(61") • (It is preferred that a component not Use a 
Rule.) The attributes of the Uses relationship 61, 61', 
61" are as defined previously- In the CASE context, it 
10 is preferred that a Component not be a First Participcoit 
unless another Comp6nent is a Second Participant in the 
relationship . 



A relationship not previously defined is "Converses" 62. 
Converses 62 is used to describe a Rule 60 connecting to 
15 a Window 63. (It is preferred that a Rule Converse with 
only one Window) . Only those Rules which are resident 
in a node with an I/O device including a cathode-ray 
tube may Converse with a Window. 

The attributes of the Converse relationship 62 eire the 
20 First and Second Participants. The First Participant 
attribute identifies the Rule instance in question, 
while the Second Participant Attribute identifies its 
Window instance. 

The "Owns" relationship 65 is used to connect Riiles 60, 
25 Components 64 and Windows 63 with Views 68, thereby 

associating with a Rxile 60, Component 64 or Window 63 a 
specific data interface. 

The attributes of the Owns relationship 65 are the First 
Particip2mt, the First Participant's entity type, the 
30 Second Participant, and the View Usage. The First 

^Participant attribute can be a Rule, Component or Window 
name ( i>e. ^ the identification attribute for a certain 
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Rule, Component or Window instance) . The First 
Participant's entity type attribute will specify Rule, 
Component or Window* The Second Participemt attribute 
will be the identification attribute for the View 
5 instcoice participating in the Owns relationship 65. The 
View Usage attribute will specify a directionality to a 
View ("In" for an Input View cind "Out" for an Output 
View for Rules and Components; "InOut" (bidirectional 
View for Windows as well as Rules and Components) • 

10 The "Includes" relationship 67 is used to nest a View 
within another View, or to connect a View with its 
constituent Fields (67' )• A View 68 may therefore 
Include a View 68 or a Field 69. 

The attributes associated with the Includes relationship 
67, 67' comprise the First Participant attribute (which 
is the View instance in question) ; the Second 
Participant attribute (which is either the nested View's 
or Field's identification attribute) , the Second 
Participant's entity type (which would either be View or 
Field) ; the Sequence Number attribute (which indicates 
for a View that has nested Views and Fields the order of 
nested Views and Fields) ; and the Occurs Number of Times 
attribute (which indicates how many associations there 
are between the First Participeint View and Second 
Participant views; this attribute will be zero for Views 
which Include only Fields) . 

Note that the Refers relationship 66 is similar to the 
Refers relationship 47 (see Figure 3a) in the general 
Model, but it associates either Rules 60 or Components 
30 64 to a Data Entity 48. As such the First Participant 
attribute in this relationship may include the 
identification attributes from either the Rule or 
Component instance in question. 
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Application of tHe SDS Entity-Relationship Model 
to Specific Softveure and Hardware Configurations 

The application of the above-defined SDS Entity- 
Relationship Model to specific software and a computer 
5 system requires that the specifics of the software axid 
the system be identified to the Repository 5 according 
to the specifications of the Model. That is, when 
designing a new application, a programmer can store in 
the Repository 5 a description or representation of the 

10 application and hardware as instances of the entity and 
relationship types provided by the Model, (For purposes 
of consistency, both the actual software and hardware of 
a computer system and the representation of such 
software and hardware on the Repository 5 will be 

15 referred as "entity instances." it will be clear from 
the context of discussion which is being referenced, 
actual software and hardware or their representation in 
the Repository 5. "Instances" are to be distinguished 
from "types", which form the SDS Entity-Relationship 

20 Model as discussed above) . 

When updates to an application aire made, the Repository 
5, containing specific entity and relationship instances 
descriptive of the application and the related hardware, 
can be examined by SDS to determine information required 
25 for software distribution. 

However, the SDS Entity-Relationship Model described 
above has been designed to provide not merely for entity 
and relationship types which are required for software 
distribution, but also a structure useful for orderly 
30 and logical applications software design. The design of 
the SDS Entity-Relationship Model thus achieves great 
efficiency since for a given software application the 
entity euid relationship instances useful for software 
distribution cem in fact be stored in the Repository 5 
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as a natural consequence of software design, requiring 
little or no further refinement for software 
distribution purposes. This feature of the SDS Entity- 
Relationship Model can be cpiite useful when combined 
5 with CASE software designed for Entity-Relationship 
Model compatibility. Thus, with an automated and 
compatible CASE tool, a designer can design software and 
build entity and relationship instances in the 
Repository useful for software distribution at the same 
10 time. 

The SDS Entity-Relationship Model is equally appliceOjle 
to facilitate software distribution of applications 
written without the Model in mind. The structure of the 
SDS Entity-Relationship Model is generic enough to 

15 describe the specifics of any application. All that 
need be done is to logically describe an existing 
program and computer system in terms of the categories 
of entities and relationships provided by the Model. 
Once this is done, the specific instsmces of such 

20 entities and relationships are stored in the Repository 
5 for future use in the distribution of modified 
software entity instances. 

Regardless of which system is employed to develop the 
entity and relationship instances for a given 

25 application, the result of such development is a 

Repository 5 containing a representation of entity and 
relationship information. This information is 
illustrated by way of example in Figure 3c. Regarding 
the instances of entities, note that a given application 

30 or Function instance 8 is logically composed of a 

highest level or Root Process instance 9, which intern 
is comprised of one or more lower level Process 
instances 10, 11. The lowest level Process instances 11 
are each comprised of a highest level or Root Program 

35 instance 12, which may call one or more subordinate 
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Program instances 13. Each of the subordinate Program 
instances 13 may in turn call other stibordinate Program 
instances 14, and so on. Any of the Program instances 
may have access to or need for Data Entity instances 15 
5 which comprise individual data Value instances 16. The 
relationship instances among the entity instances eire 
indicated in the Figure. 

Leaf Processes are the only Processes which directly 
relate to one or more programs/data entities. All other 

10 Processes (for example Root and Node Processes) are 
merely logical combinations of Leaf Processes. 
Furthermore, a Function is merely a collective term for 
the logical organization of processes. For the purposes 
of software distribution, no description of software 

15 entity and relationship instances above Leaf Processes 
in a given software application is required. However, 
such higher level software entities (Function, Root and 
Node Processes) emd their associated relationships are 
useful in conjunction with software design efforts 

20 (referenced above) and could be present in such software 
entity instance representations stored in the 
Repository 5. 

Regarding relationships depicted in Figure 3a, note that 
in Figure 3c each interconnection between software 
25 entity instances is represented by one of the Refines, 
Defines, Uses, Refers or Members relationship instances. 

For a given representation of applications software 
entity instances stored on the Repository 5, the 
specifics of each entity instance are recorded in the 
30 Repository 5. The Repository 5 as shown in Figure 3c, 
for example, contains entries not only for the 
identification of each entity instance, but for all 
attributes pertinent to that entity type. For example, 
stored are the identification attributes of each Program 



wo 91/08542 



PCT/US90/07011 



-29- 

izistsmce comprising the application, as well as each 
Program and Data Entity instance's execution 
environment. Furthermore, stored are the specifics of 
each relationship instemce between entity instances, for 
5 example, the identity of each participant in a given 
relationship. In this way, any application can be 
completely descrdLbed. 

Besides containing a representation of a software 
application in terms of software entity coid relationship 
10 instances, the Repository 5 also contains a 

representation of computer system hardware in terms of 
instsmces of Worlcstation and Workstation Group entity 
types and their associated relationships. In addition, 
there is a description of which Workstation/Workstation 
15 Group instances have access to Leaf Processes instances. 
This description is provided by the Workstation Group to 
Process (or Workstation to Process) relationship defined 
by the SDS Entity-Relationship Model. 

If the special entities and relationships which are 
useful with CASE and other software are considered, a 
more detailed Repository 5 will be created. Figxire 3d 
depicts a portion of an exemplary Repository 5 where 
progreon instances are replaced by Rule instances 30, 35, 
36, a Component instance 32 and a Window instance 31, 
and where specific data interfaces defined by a View 
instance 33 and Field instances 34 are included. Note 
that a View instance 33 and Field instaoices 34 do not 
replace or eliminate the need for the Data Entity 
instances and Value instances or their associated 
relationships. Data Entity instances and Value 
instances have been omitted from Figure 3d for clarity. 

As indicated by Figure 3d, Window 31, Riae 30, 35, 36 
and Component 32 instances can share ownership of a View 
instance 33. However, Rule 30, 35, 36 and Component 32 
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instances may liave unshared multiple View instances in 
addition to one which may be shared. Also, as indicated 
in Figure 3d, a given View instance 33 may Include more 
than one Field instcmce 34. 

5 As is the case with the software entity and relationship 
insteuices stored in the Repository 5, the haxdweore 
entity instances and the hardware to software 
relationship instcinces axe stored in the Repository 5 as # 
part of the application software design process, or as 
10 part of the process of describing an existing 

application and system in terms of the SDS Entity- 
Relationship Model. 

By way of example, Figure 3e depicts the contents of the 
Repository 5 as they concern the hardware entity 

15 instances of a given system. The Leaf Process Instance 
11 shown in Figure 3e can be any of the Leaf Process 
instances shown in Figures 3c or 3d. Each Workstation 
instance 3 can be any of the Workstations instances 3 
depicted in Figures 1 and 2. The Workstation Group 

20 instances 17 are logical collections of individual 

Workstation instances 3. The Repository 5 identifies 
individual Process instances by specific Process 
attributes stored for each Process instance, as ^ 
discussed eibove. Similarly, all attributes generally 

25 stored for Workstation Group and Workstation instances, 
as defined by the SDS Entity-Relationship Model, are 
stored in the Repository 5 for the specific system in 
question. Moreover, relationship types specified by the 
Model associating Processes with Workstation Groups and 

30 Workstation Groups with Workstations are stored in the 
Repository 5 as instauices of these relationship types. 
Figure 3f depicts an exemplary portion of contents of a 
Repository 5 for systems which do not employ the 
Workstation Group entity type. As a consequence the 
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Beposltory 5 stores no instances of entitles or 
relationsbips associated with the Workstation Group. 

It should be understood that while the Repository 5 can 

m 

and does contain copies of actual software entity 
5 instcinces which comprise the software application. 

Figures 3c-f depict a portion of the Repository 5 which 
contains a representation of the software and heurdware 
of the system by virtue of entity attributes. It is 
this representation of the software and hardware entity 
10 instances, according^ to the Model, which is significant 
to the SDS process. 

The SDS Execution Environment 

Prior to proceeding with a discussion of the specific 
processing of SDS, a short discussion of the SDS 
15 execution environment will be useful. 

The two types of hardware configurations depicted in 
Figures 1 and 2 show three and two tiers of hardware 
platforms respectively. In either case however, it is 
preferred that SDS functions be executed on the 

20 mainframe processor 1, 7. This is because mainfreune 
processors are best suited for database-intensive 
processing. It should be tmderstood that a mainframe 
processor, while preferred, is not an absolute 
requirement. Therefore, in the balemce of this 

25 specification where reference is made "the processor (or 
node) executing SDS," it should be understood to mean a 
mainframe only in a preferred embodiment. 

The discussion which follows also makes mention of some 
user interaction with SDS. Generally, this interaction 
30 occurs through user operation of a worlcstation . While 
such workstation could be any workstation 3 connected to 
the network, it is convenient that a special workstation 
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or input/output device 6 be used for this purpose. 
The Impact Analysis 

After a representation of system software and hardwc^-e 
entity instances has been stored in the Repository 5 as 
5 a combination of entity and relationship instances of 
the SDS Entity-Relationship Model, a programmer may make 
modifications to one or more software entity instances 
(^'7' > Programs, Data Entities, Rules, Components, 
Windows, etc.) comprising the application. At this 
10 point, SDS can be performed beginning with the SDS 
Impact Analysis. 

The Impact Analysis (lA) fimction of SDS determines what 
effect changes to certain software entity instances will 
have on entity instances already defined in the 

15 Repository 5 and stored in the warehouse 4. The list of 
entity instances produced by the lA function, stored in 
an lA Table (lAT) of the Repository 5, will include all 
entity instances directly modified by a programmer and 
will further include all entity instances which may need 

20 to be changed as a result of the direct modifications 
(propagated changes) . A programmer once informed of 
entity instances listed in the XAT must then consider 
these entity instances and make modifications to them 
where appropriate. 



25 The lA function could determine all directly modified 
entity instances simply by adopting a list of such 
®ri"tity instemces provided by the progreuraner. However, 
it is preferred that a line-by-line comparison be made 
by the lA fxanction between the unmodified application 

30 and the modified application, with all modified entity 
instemces being noted in the lAT. 

The lA function determines possible propagated changes 
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by determining all Program instances which call and 
which are called by the directly modified Program 
instances. SDS does this by scanning the Repository 5 
for all instances of modified Program instances as 
5 either the First Paurticipemt or Second Participant 

attribute in Uses relationships. When such a situation 
is encountered, the corresponding Second or First 
Participant attribute Progretm instances respectively eure 
noted in the lAT. 

10 If the entities of View and Field are employed in the 
SDS Entity-Relationship Model for the application in 
question, SDS will scan the Repository 5 for all Program 
instances which Own Views Owned by the modified ProgrcOQ 
instances. These Program instances are then listed in 

15 the lAT. Also, SDS will scan the Repository 5 for all 
View instances which Include Field instsoices which eire 
defined to the modified Program instance. Then, all 
Progreim instances which Own such View instances are 
listed in the lAT. 

20 Whether or not the View/Field entities are used, the 
scanning done by SDS is needed to help identify 
Program-to-Program data interfaces which may have been 
altered by a modification to one of the Program 
instances. Any Program instance which calls or is 

25 called by a modified Program instance, or which shares 
Views/Fields with a modified Program instamce (Rule, 
Component, Window) may have to be modified to account 
for changes to a data interface. 

The lA function of SDS also determines possible 
30 propagated changes by identifying all Data Entity 
instances which have been directly modified by a 
programmer and then by scanning the Repository 5 for all 
other Progrem instcmces which have access to ( i.e. , 
Refer to) such Data Entity instemces. This is performed 
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since a programmer may directly modify a Data Entity 
instauice by changing some aspect of data format, but 
only accoiant for such alteration in, say, the one 
Program instwce known to the programmer to have access 
5 to the Data Entity instemce. However, because other 
Program instances may also access the Data Entity 
instance, these Program instances may need modification. 

Thus, a progrEunmer would have to consider all these 
additional Program instances to determine whether 
10 modifications are required as a propagated effect of his 
direct modifications. The lA function, therefore, 
provides the progreanmer with information stored in the 
lAT of the Repository 5 which delineates the basic 
information needed to maJce such determinations. 

15 The 2QDove described lA function identifies all directly 
modified entity instances and all possible entity 
instances which may need to be changed as a result of 
direct modification (propagated changes) . An 
alternative form of lA, referred to herein as "IA2", 

20 identifies directly modified entity instances in the 
same way, but identifies entities requiring propagated 
changes in a different manner. Propagated changes axe 
determined changes based on the significance of given 
direct modifications to other related entity instances. 

25 1A2 is premised upon the fact that a direct change to an 
entity instance may not affect the executable form of 
other entity instances which would otherwise be 
identified by the I A function. These other entity 
instances, which may be numerous, need not be 

30 distributed by SDS. As a result, IA2 can provide a more 
efficient system for distributing software. 

IA2, like lA, identifies all directly modified entity 
instemces by, e.g., performing a line-by-line comparison 
of modified and unmodified applications. IA2, however. 
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goes further in that it assigns a "Change Class** to the 
type of change made directly by the prograunmer. The 
Change Class is stored in the lAT for each directly 
modified entity instance. 

5 Cheoige Classes cure defined to indicate the signif iccuice, 
in terms of the extent of propagated effect of a given 
direct modification to an entity instwce. For example, 
a Change Class of 01 might indicate a major propagation 
effect, while a Change Class of 02 might indicate a more 

10 modest effect, if any effect at all* Generally, a 

Change Class assigned to a modified entity instance is a 
function of the entity attribute changed by the direct 
modification. Some entity attributes concern only the 
directly modified entity, while other attributes concern 

15 other entity instsmces as well as the one modified. 
Depending on the natxxre of entity instajices and their 
attributes. Change Classes may be defined to require no, 
some or many propagated changes. 

For a given entity relationship model. Change Classes 
20 for an entity type are determined by considering the 
propagtive effect of chemges to the attributes of the 
entity type. Thus, changes to each attribute of an 
entity type are considered for their propagative effect 
— the extent to which other entity types superordinate 
25 to the one in questions are affected by such changes. 

If changes to certain attributes of an entity type share 
a propagative effect, then such attributes are grouped 
together in a Change Class. 

The following table (Table I) defines Change Classes for 
30 the entities of the Entity-Relationship Model useful 
with certain CASE software. The information presented 
in Teible I is used by XA2 to assign a change class to 
directly modified entities. 



T^LB I 

Meaning 

Rule source code has changed. 

Rule EXECENV or ASYNC fields 
have changed. 

Componenl: source code changed* 

Component: EXECENV or ASYNC 
f ields have chcinged. 

Window soxirce code or HELP file 
has changed. 

Set FORMAT, LENGTH, SCALE or 
SETVAL SYMBOL fields have 
changed. 

SETVAL Relationship text has 
changed . 

Pield FORMAT, LENGTH, SCALE or 
PIC STORAGE fields have 
chaoiged. 

View VUOWNS field has changed. 

As shown in Table I, the first column of information 
defines entity types. These entity types may have one 
or more Change Classes. As em excimple, the entity type 
"Set" appears twice and has, therefore, two Change 
Classes associated with it. (A Set is an enumerated 
list of Values. Each Value is given a symbolic 
reference, A Set is defined by the following 
attributes: (1) Set Name, used to uniquely identify the 
Set; (2) Set Description, used to describe the Set 
instance; (3) Element Format, used to describe the 
format of set elements; (4) Element Length, describing 
the length of the Set elements; (5) Element Scale, 
describing the number of decimal places for decimal 
fields; (6) SETVAL Symbol, describing the name of a 
given Value in the Set). According to Table 1, shoxild 



Entity Change Class 



RULE 01 

RULE 02 

COMP 01 

COMP 02 

WINDOW 01 

SET 01 

SET 02. 

FLD 01 

VIEW 01 
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any of the Format, Ijength, Scale or SETVAL Syxnbol 
attributes cliemge, by virtue of a modification by a 
progreunmer to the Set instance in question, the Set's 
Change Class will be designated as 01* If , on ^e ot:her 
5 hand, the value of da^ represented by a given SETVAIi 
Symbol changes, the Change Class associated with that 
Set is 02. 

The significance of a given Change Class to propagated 
changes is shown in Table 11 • 

10 TABLE XI 

Propagative Effect Matrix 



20 



30 



TYPE 


CH6 
CLA 


RUL 


COM 


WIN 


VJ5H 


FLD 


SET 


PARENT 
RTTIi COM 


TOP 
RPI. 


PRO 


RUIjE 


01 


y 












N 




Y 


Y 


RUIjE 


02 


Y 












N 




Y 


Y 


COMP 


01 




Y 










N 


N 


Y 


Y 


COMP 


02 




Y 










N 


N 


Y 


Y 


WINDOW 


01 


N 




Y 








N 




N 


Y 


SET 


01 


Y 


Y 


N 






Y 


N 


N 


Y 


Y 


SET 


02 


N 


N 


N 






Y 


N 


N 


N 


Y 


FLD 


01 


Y 


Y 


N 


Y 


N 




Y 


Y 


Y 


Y 


VIEW 


01 


Y 


Y 


N 


Y 


N 




Y 


Y 


Y 


Y 


VAI^S 


01 


Y 


Y 


Y 






Y 


Y 


Y 


Y 


Y 



Table II indicates, for a given entity type with a given 
35 Change Class (first two columns) , other entity types 

(top of each coliamn) , beginning with ("RtJL") which will 
feel a propagated effect from the changed entity. The 
"Y" entries in the table specify the propagative effect, 
in terms of superordinate entity types, of changes to an 
40 entity instance listed in the "TYPE" column of the 
table. Depending on the attribute (of the entity 
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instance) directly modified, a given Change Class is 
implicated (see Table I) . Specifically, for a modified 
Set with a Change Class of 01, Table II indicates, by 
virtue of the "Y" entries, that all Rules and Components 
5 associated with that Set, and the Process, will 

experience a propagated effect (for example. Rules and 
Components will have to be reprepeured in executable form 
to account for the changes in the modified Set) . In 
contrast, a modified Set with Change Class 02 need have 
10 only itself and the Process reprepared (see "Y" under 
"Set" and "Pro" column only) . That is. Rules and 
Components associated with that Set need not be 
reprepeured. 

For every entry in the lAT indicating a modified 

15 software entity instance, IA2 traverses Table II to 
determine which other entity types may be affected by 
the modification. In the case of a modified Set of 
Change Class 01, IA2 identifies the Rule, Component and 
Process entity types. IA2 then scans the Entity- 

20 Relationship representation of the software in 

Repository 5 to determine all entity instsmces of the 
identified entity types (e.g.. Rule, Component and 
Process instances) which are related and superordinate 
to the modified entity instance in the software 

25 hierarchy of the Entity-Relationship representation. 

Each of these related entity instances is identified in 
a table for later use in and testing and software 
distribution. It may be that for any one entity 
instance in the lAT, another entity instance is 

30 identified as having a propagated effect that has been 
identified previously. In this case, the entity 
instance need not be identified a second time in the 
table. 

As a result of IA2, a table is built, referred to as the 
35 IA2T, which includes all directly modified entity 
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ins1:ances as well as all instances which are a resiilt of 
the propagation of direct modifications. This table 
serves the SDS like the lAT discussed above. 

Software Modification 
5 and lA Process Manacfement 

In terms of managing the software modification and lA 
processes (hereinafter, "lA" refers to either lA or IA2 
processes) , it is preferred that all Progrsim/Data Entity 
instance modifications, whether direct or propagated, 

10 occur not on the Repository 5 or the Warehouse 4 (which 
are actually "production" environments storing software 
and relational databases accepted as operational) , but 
rather on a "Development Repository" 5'. This 
Development Repository 5' is either physically or 

15 logically separate from other storage in the computer 
system in question and allows a programmer to make his 
direct modifications, and any necessary propagated 
modifications (as a result of lA) without the danger of 
contaminating existing storage. Thus, the Development 

20 Repository 5' contains the modified software 
application, as well as a modified entity and 
relationship representation of the software, if such is 
called for. It is preferred that the Development 
Repository 5' be connected to the mainframe processor 1, 

25 7 accessible through a Workstation 3, 6, however, it may 
simply be a data base local to a given Workstation 3 
connected to the network. 

It is further preferred that an lA be performed on a 
copy of the modified application stored in a "Staging 
3 0 Repository" 5", where application quality assurance 
testing Ccm also be performed. Like the Development 
Repositoiry 5', the Staging Repository 5" should be 
logically or physically distinct from other system 
storage and be connected preferedaly to the mainframe 1, 
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7. Also, the Staging Repository 5" can be accessible 
through any processor/inpiit-output conbination, but is 
typically accessible, as is the Development Repository 
5', through a Workstation or Input/Output terminal 3, 6 
connected to the mainframe l, 7. Generally, quality 
assurance testing of a modified application requires 
installation of the application in executable form on 
its intended hardware environment (for example, a 
three-tiered environment) so that the software can be 
completely exercised. However, this testing activity in 
general does not require distribution of the modified 
software to more than one processor in a given hardware 
tier. 

Quality assurance testing is typically controlled from a 
15' single Workstation or input/output device 3, 6 with 
access to the modified software stored on the Staging 
Repository 5". For purposes of identification, this 
Workstation or input/output device 3, 6 will be referred 
to as the "Quality Asstirance Workstation"; it can be 
20 located anywhere in the system or network. Of course, 
quality assurance testing requires that modified 
software entity instances be converted into executable 
form for use in testing by the various hardware 
platforms (tiers) of the system. 

25 As a result of an lA and quality assurance testing, 

further modification to the application may be required. 
If so, the further modification should be made 
preferably on the Development Repository 5', and lA and 
quality assurance testing should be repeated on the 

30 Staging Repository 5". It is preferred that repetition 
of the lA, quality assurance testing and Program 
modification sequence be continued until quality 
assurance testing indicates that the application 
functions as desired. 
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Hhen all appropriate en-ti-ty ins-kance modifications have 
been made emd tested, it is further preferred that the 
modified and tested application, along with its entity 
and relationship representation, be moved to the 
5 Repository 5 for a final IA« Should this lA indicate no 
further difficulties, the modified application cem be 
accepted for use as a "base line" or production version. 
(Should further modifications be required, it is 
preferred that they be made on the Development 
10 Repository 5' with an lA and quality assuramce testing 
occurring at the Staging Repository 5".) 

At this point, a "Release" of the modified software 
entity instances can be built. Since as a result of a 
final satisfactory lA from the Staging Repository 5" to 

15 the Repository 5 both Repositories will contain copies 
of the same software instances and entity and 
relationship representation, it will be understood that 
a Release could be built from either the Staging 
Repository 5" or the Repository 5. For purposes of 

20 explanation, it will be assumed that a Release will be 
built from the Repository 5. 

Building a Release 

A Release is defined as the logical unit of work to be 
distributed by SDS. This logical unit of work in effect 

25 is the total difference between the ciirrent version of 
an application as it exists in the Warehouse 4 ( i, e> , 
the unmodified version) and a modified application as it 
exists in the Repository 5 ( i>e, , all modified software 
entity instances) • The existence of each Release is 

30 recorded in a Release Entity TeO^le (RET) in the 
Repository 5. 

A Release is described by a "Release Configuration" 
which is comprised in part of a Release-to-Entity 
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Relationship Table (RERT) stored in the Repository 5, 
The RERT contains an entry (or row) for each software 
entity instemce to be distributed by SDS. 

The RERT is comprised in part of the list of all 
5 software entity instcmces affected by progranmer 

modification. This list (or column in the RERT) is the 
result of the SDS lA processing discussed eUsove aaid is, 
in effect, the lAT. 

The RERT is fiirther comprised of a list of Physical File 
10 Names which will be identical to the list of modified 
eii"tity instances except that should a modified entity 
instance be comprised of more than one physical file, 
extensions are employed to augment the entity name thus 
separating individual physical files associated with a 
15 single entity instance. This list of physical files 
appears as a second column in the RERT. 

A third column in the RERT consists of Path Names for 
each affected entity instance. A Path Name is chosen to 
be a function of the attributes of a software entity 
20 instance. 

A fourth column in the RERT consists of Logical File 
Names which are, as explained below, versions of 
Physical File Names which separate Physical Files on a 
Release basis. 

25 The Release Configuration is further comprised of a 

Release to Process Relationship TeQ)le (RPRT) . Like the 
RERT, the RPRT is stored in the Repository 5. The RPRT 
contains an entry for all Leaf Process instances which 
are comprised in whole or in part of modified software 

30 entity instzmces. Entries to the RPRT are made by a 

scan of the Repository 5 for Process instamces which are 
coii5)rised of constituent software entity instances which 
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appear in tlie XAT for the Release. These associations 
are provided by the Process to Program, Progreuu to 
Program and Program to Data relationships discussed 
£ibove. 

5 Thus, for each Release (as indicated by each entry in 
the RET) there are entries in associated tables, the 
RERT and the RPRT. Each of these tables is stored in 
the Repository 5 . Once entries to the RERT and RPRT are 
made by SDS, the remaining activities required for 

10 software distribution are the incorporation of modified 
entity instances into the Warehouse 4 and the physical 
transportation of individual software entity instances 
to their appropriate Workstations 3 ( i«e> , nodes to 
which software is to be distributed) . It is preferred 

15 that the performance of these remaining steps be under 
the control of one centralized control mechanism, e>q. , 
the mainframe 1, 7 of the three and two tiered computer 
systems of Figxires 1 amd 2, respectively (operated by a 
user at an associated worlcstation 6} • In this way, any 

20 issues concerning a Release which arise among system 
users who aore located at various worlcstations 3 can be 
dealt with in an orderly, organized fashion. Although 
these steps can be performed in a decentralized fashion, 
e,g, , by multiple controlling processors or by multiple 

25 users at Workstations 3 in the network, the centralized 
control approach is logistically simpler to implement. 

Incorporating Modified Entities into the 
Warehouse 



At this point in the SDS process, modified software 
30 entity instances have been tested for validity amd 
quality assxirance, and entries to the RERT and RPRT 
tcdDles have been made. The next step is the process of 
saving the modified software entity instemces in the 
warehouse 4. 
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When software entity instances are saved in the 
Warehouse 4, they do not over-write or eliminate 
previously released versions of the same entity 
instances. Rather, each modified entity instance is 
5 saved on a Release basis. To facilitate storage on a 
Release basis, SDS defines for each such entity instance 
a Logical File Name. Logical File Names are versions of 
entity Physical File Names contained in the RERT. 
Logical File Names are chosen as functions of both the 

10 Physical File Name and the Release Name (from the RET) . 
SDS then creates an "Upload Order" containing a Logical 
File Name for each Physical File Name in a Release. An 
"Upload order Table" (UOT) is maintained in the 
Repository 5 to store status information about the 

15 processing of the Upload Order. 



20 



The Upload order is then transmitted over the network to 
the node which was responsible for the coordination of 
quality assurance testing (the Quality Assurance 
Workstation) . This node, in response to this Order, 
collects the tested software entity instances, which are 
in executable form, from the test nodes and transmits 
the software entity instances over the network to the 
node which controls the Warehouse 4. The software 
entity instances are then stored in the Warehouse 4 
25 under their Logical File Names as specified by the 

Upload Order. (Note that such modified software entity 
instances coxild have also been sent from either of the 
Repositories 5, 5" to the Warehouse 4 depending on the 
embodiment chosen. However the Repositories 5, 5" may 
30 not have stored executable forms of the software entity 
instances, should software entity instances be stored 
in non-executable form in the Warehouse 4, they must be 
converted prior to execution on Workstations 3.) The 
Logical File Name generation process provides a distinct 
35 identity to every version of every entity instance 
stored in the warehouse 4. 
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Mhen all software en-tity ins-temces of the Release are 
stored in tbe Wcurehouse 4, the Upload Order is completed 
and an "Upload Complete" status is recorded in the UOT 
stored in the Repository 5. 

» 

5 At this point, modified software entity instances can be 
distributed to the appropriate Workstations 3 (or nodes) 
by SDS. 

Physical Software Distribution (Release Download) 

Once a Release has been successfully uploaded to the 

10 Warehouse 4 (so indicated by the Upload Complete status 
recorded in the UOT) , a Release Download can occur. In 
order to physically distribute software entity instances 
( i>e. , Download a Release) , it is necessary for SDS to 
determine which Workstations 3 are to receive particular 

15 modified software entity instances. This determination 
is made by SDS's scanning of the tables of the 
Repositoiry 5 to associate modified software entity 
instances in a Release to their Process instances, and 
to associate such Process instances to particular 

20 Workstations 3. Specifically, the RPRT for the Release 
in question is scanned by SDS for all Process instances 
affected by the Release. SDS searches the Workstation 
Group to Process relationships of Repository 5 to 
determine those Workstation Group instances which have 

25 access to the Process instances affected by the Release 
( i.e. , those Process instances in the RPRT; see Figure 
3e) . Furthermore, SDS searches the Workstation to 
Workstation Group relationships of Repository 5 to 
determine those Workstations 3 which are members of the 

30 identified Workstation Group instances. (Should the 
particular computer system in question not employ the 
Workstation Group entity, SDS would search the 
Repository 5 to determine directly those Workstations 3 
that have access to those Process entities affected by 
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tne Release by virtue of tbe Workstation to Process 
relationship.) 

At this point, a logical relationship has been made 
between Wortetations 3 and Process instances affected by 
5 a Release. SDS then scans the RERT to determine all 
entity instances affected by the Release. Furthermore, 
SDS scans the Repository 5 to determine all Process 
instances which are comprised of such entity instances. 
This is done by tracing, for each such entity instance 

10 in the Release (as indicated by the RERT) , a path 
upwards in the softwcure hierarchy, through the 
relationship and entity instances stored in the 
Repository 5 (see Figure 3c), until each Process 
instance is identified. The Repository 5 therefore 

15 provides the association between Processes in the 
Release and affected entity instances. 

The logical relationship between Workstations 3 and 
Process instances, affected by a Release, together with 
the logical relationship between Process instances 
affected by a Release and affected entity instance, 
provides the basis for the creation of specific 
"Download Orders." 

A Download Order is built by SDS for each affected 
WorJcstation 3. A Download Order (DO) is a list of the 
modified software entity instances for each Workstation 
3 identified in the technique described above. Each 
modified software entity instance is identified in a DO 
by its Physical File Name, Logical File Name and its 
Path Name. Each DO is identified by a specific DO 
30 Number. The DO's are then sent by the node executing 
SDS through the computer system network for storage at 
each affected Workstation 3. A "Download Order Table" 
(DOT) is maintained by the Repository 5 to store status 
information associated with the processing of DOs. 



20 
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Each affected Worksta'tion 3 processes a DO In part by 
retrieving all specified softweure entity insteuices (by 
Iiogical File Name) froia tbe Warehouse 4 into its own 
local warehouse dateO^ase. The local warehouse is 
5 storage which is amcillary to that used for storing 

baseline versions of software entity instsmces executed 
by the Workstation 3* The downloaded software entity 
instances are saved in the local warehouse under the 
same Logical File Neimes as used in the warehouse 4. Xt 

10 is preferred that such entity instances be saved in a 
compressed file (to save space) identified by the 
associated DO Number. It is fxirther preferred that each 
Workstation which has stored modified entity instances 
(in its local warehouse) pass a completion status back 

15 through the network to the node executing SDS for 
storage on the DOT in the Repository 5 to reflect 
completion of the Download process. At this point, the 
Release ( i.e. , modified software entity instances) has 
been distributed or "downloaded" to those Workstations 3 

2 0 which require updating • 

Release Installation 

After modified software entities have been downloaded to 
a Workstation's local warehouse database, installation 
of such entity instances ceui occur at the appropriate 

25 time. Typically modified software entity instances are 
installed for use on every Workstation 3 (that has 
received the downloaded software entity instemces) at 
the seuDie time. The time chosen should correspond to 
when such Workstations 3 are not executing the 

30 tmmodified application. 

SDS provides for installation of modified software 
entity instances through the generation of Install 
Orders in response to user instructions to install a 
Release « SDS generates its Install Orders by first 
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searching the DOT for the Release in question in the 
Repository 5 to determine all Worlcstations 3 that have 
received downloaded software (i^. Download status 
checked) . Next, SDS constructs the Install Orders. 
5 These Orders are sent over the network to each 

identified Workstation 3. (Note that in a three tiered 
system, the mini-computer 2, receives the Install Orders 
from the mainframe 7 (which is executing SDS) and 
directs them to the individual Workstations 3 over the 
10 network. However, in a two tiered system the mainframe 
1, 7 both generates and directs such Orders to the 
appropriate Workstations 3.) Each Install Order 
contains a number which matches the DO Number previously 
received by the Workstations 3. SDS maintains an 
15 "Install order Table" (lOT) in the Repository 5 to store 
status information associated with the processing of 
lOs. Prior to executing each Install Order, each 
Workstation 3 saves (or "backs out") previous versions 
of modified software entity instances and store them in 
20 compressed a file. This compressed file is preferably 
identified by the DO Number with an extension indicating 
its status as a back out file. The entity instances to 
be backed out are identified by the Workstation 3 by 
reference to the DO it has previously received and 
25 stored. 

Once in receipt of an Install order, and after having 
backed out previous versions of the modified software 
entity instances, a Workstation 3 can install the 
modified software entity instances for regular baseline 

30 application processing. The installed entity instances 
are saved preferably under their Physical File Names 
listed in the DO for the Workstation 3. They are stored 
at an address identified in part by their associated 
Path Names (also indicated in the DO) . With instal- 

35 lation completed, an "Installation Complete" status is 
returned by the Workstation 3 in question and this 
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information is saved in the lOT of the Repository 5. 

The backed out entity instances stored in the 
Workstation local warehouse have use when it is 
desirable to restore a prior Release. To accomplish 
5 this, 5DS issues a Back Out Order to all affected 

Workstations 3. The Back Out Order includes a DO Number 
associated with the Release to be backed out ( i-e> , de- 
installed) • The compressed file stored on the local 
warehouse identified by the corresponding DO Number 
10 (with a backout extension) is then used as the file to 
be installed at the Workstation 3 for baseline 
processing. 

For purposes of Release Downloading^ Installation and 
Back-Out, it is preferred that Workstations 3 have a 

15 time interval designated during which such activities 
can occur. This can be achieved in several ways 
including the creation of an "SDS Mode" for each 
Workstation 3 in which each can process Download, 
Install or Back-Out Orders. The "SDS Mode" could occur 

20 at a designated time or at various times determined by 
SDS (in the latter situation, SDS could issue an SDS 
Mode commcind to the various Workstations 3 in the 
network informing them of when to switch to SDS Mode and 
for how long to remain in the Mode) . 

25 Summary of Detailed Description 

The representation of computer system entity instances 
and the relationships between such instances as stored 
in the Repository 5 as a result of software design, as 
well as the construction of special relationships stored 
30 in tables in the Repository 5 for the purposes of 

software distribution, are summarized by way of example 
in Figure 4. Figure 4 depicts the modified software 
entity instances (programs 18 and Data 19) which are the 
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resiilt of direcrt and propagated modifications to the 
software entity instances. All such nodified entity 
instances, whether of the direct or propagated type, 
originate in the Development Repository 5'. The need 

5 for propagated modifications is identified by an lA and 
quality asstirance testing, both associated with the 
Staging Repository 5". (Should propagated modifications 
be indicated, these are generated back at the 
Development Repository 5'.) Whether resulting from 

0 direct or propagated modifications, all modified entity 
instances are listed in a table (lAT) as a result of the 
lA. Quality assurance testing associated with the 
Staging Repository 5" occxirs with modified entity 
instcmces in executable fojnn. 

5 When quality assurance testing is completed, a Release, 
described by a Release Configuration, can be built by 
SDS. A Release Configuration is based on two tables, 
the RERT and the RPRT. The rert associates Physical 
Pile Names and Path Names with each entity instance to 

J be distributed by SDS. The RPRT associates with the 
Release all affected Leaf Processes 21. 



To distribute software, SDS issues certain orders to 
various nodes in the network. One of these is the 
Upload Order, issued to the node controlling the 
i5 Warehouse 4, to collect and store software modified 
entity instances under a Logical File Name. 

Another of these is the Download Order, issued to 
Workstations 3, to retrieve from the Warehouse 4 
particular modified software entity instances and store 
O them in a local warehouse imder Logical File Names. The 
DOS are constructed by SDS from a scan of the RERT, 
RPRT, and the softweire and hardware entity and 
relationship instance representations maintained by the 
Repository 5. 
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In order 1:o implement a Release Configuration ( i>e> , 
install a Release) , Install Orders are created by SDS 
and sent to all affected Workstations 3. The 
Workstations 3 i mplement the Install Orders by saving 
5 previous versions of entity instsmces and by installing 
newly modified entity instmces. 
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In the Cla^Tng j 

1. A method for distributing software in a 
computer system, the software comprising o 
or more software entity instances and the 
computer system comprising one or more 
hardware entity instances, the method 
coaQ>risdLng the steps of: 

storing information in a database 
descriptive of the softwcure entity 
instances, hardware entity 
instances, and relationship 
instances between such hardwcore 
and software entity instances; 

modifying one or more software 
entity instances; 

scanning the database to associate 
with each modified software entity 
instemce one or more hardware 
^tity instances to receive each 
such modified software entity 
instance ; and 

distributing one or more modified 
software entity instances to one 
or more associated hardware entity 
instances. 

2. The method of claim i wherein the step of 
storing information is performed according 
to an entity-relationship model. 
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3. The net:hod of claim 1 vherein the software 
entity instances comprise one or more 
program instances. 

4. The method of claim 1 wherein the software 
entity instemces comprise one or more data 
entity instances. 

5. The method of claim 1 further including the 
step of: 

storing one or more modified 
software entity instsmces in a 
database ; and 

wherein the step of distributing one or more modified 
software entity instances comprises: 

communicating one or more modified 
software entity instances from 
said database to one or more 
associated hardware entity 
instances • 

6. The method of claim 2 wherein the entity- 
relationship model comprises entity and 
relationship types, the entity types 
comprising : 

value, which describes a datum; 

data entity, which describes a set 
of one or more values; 

program, which describes a 
software routine; 
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processr wliich describes a set of 
one or more programs; and 

workstation, which describes a 
hardware node in a computer 
system; 

the relationship types comprising: 

data entity to value, which 
describes the association of a 
value to a data entity; 

progrram to data entity, which 
describes the association of a 
data entity to a program; 

progrcUD to program, which 
describes the association of a 
program with another program; 

process to program, which 
describes the association of a 
program to a process; and 

workstation to process, which 
describes the association of a 
process to a workstation. 

7. The method of claim 6 wherein the stored 
information comprises: 

a process instsmce; 

one or more program instances; 

one or more process to progrcua 
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relatiionship instiances, each such 
relatilonshlp ins-tance relating a 
program ixistamce to the process 
instance; 

one or more workstation instances; 
coid 

one or more workstation to process 
relationship instcuices, each such 
relationship instance relating a 
workstation instance to the 
process instance. 

8, The method of claim 7 wherein the stored 
information further comprises: 

one or more data entity instances; 

one or more value instances; 

one or more data entity to value 
relationship instances, each such 
relationship instance relating a 
data entity instance to a value 
instance ; audi 

one or more program to data entity 
relationship instances, each such 
relationship instance relating a 
program instance to a data entity 
instance . 

9. The method of claim 6 wherein the program 

entity type comprises a rule entity type and 
wherein the process to progreim relationship 
type comprises a process to rule 
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relatiionsliip type. 

10. The method of claim 9, wherein the stored 
information comprises: 

a process instance; 

one or more rule instances; 

one or more process to rule 
relationship instances, each such 
relationship instance relating a 
rule instemce to the process 
instance ; 

one or more workstation instances; 
and 

one or more worlcstation to process 
relationship instances, each such 
relationship instance relating a 
worJcstation instance to the 
process instance. 

LI. The method of claim 10, wherein the program 
entity type fiirther comprises a component 
entity type and wherein the program to 
program relationship type comprises a rule 
to component relationship type and wherein 
the stored information further comprises: 

one or more component instsmces; 
and 

one or more rule to component 
relationship instances, each such 
relationship instance relating 
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each component instance to a rule 
instance • 

12. The method of claim 10, wherein the program 
entity type fxirther comprises a window 
entity type and wherein the program to 
progr2m relationship type comprises a rule 
to window relationship type and wherein the 
stored information further comprises: 

one or more window instemces; and 

one or more rule to window 
relationship instances, each such 
relationship instance relating a 
window instance to a rule 
instance . 

13. In a mass storage device, a database for 

storing information according to an entity- 
relationship model, the database for use in 
distributing software in a computer system, 
the model comprising entity and relationship 
types, the entity types comprising: 

value, which describes a datum; 

data entity, which describes a set 
of one or more values; 

program, which describes an 
individual software routine; 

process, which describes a set of 
one or more programs; and 

workstation, which describes a 
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hcurdvare node in a computer 
system; 

the relationship types comprising: 

data entity to value, which 
describes the association of a 
value to a data entity; 

program to data entity, which 
describes the association of a 
data entity to a program; 

prograaa to program, which 
describes the association of a 
program with einother program; 

process to program, which 
describes the association of a 
progrcua to a process; and 

worlcstation to process, which 
describes the association of a 
process to a workstation, 

14, The database of claim 13 wherein each entity 
type of the model is described by a set of 
attributes, the set of attributes for a 
program comprising a identifier attribute 
and an execution environment attribute. 

15. The datcODase of claim 13, wherein the 
information comprises : 

a process instcoice; 

one or more program instsmces; 
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one or more process *to program 
relationship instances, each such 
relationship inst€mce relating 
each program instance to the 
process instance; 

one or more workstation instances; 

one or more workstation to process 
relationship instances, each such 
relationship instsmce relating 
each workstation instcince to the 
process instance. 

16. The database of claim 15, wherein the 
information further comprises: 

one or more data entity instances; 

one or more value instances; 

one or more data entity to value 
relationship instances, each such 
relationship instance relating a 
data entity instance to a value 
instance ; and 

one or more program to data entity 
relationship instances, each such 
relationship instance relating a 
program instance to a data entity 
instance • 

17, The database of claim 13 wherein each 
relationship type of the model is described 
by a set of attributes, the set of 
attributes for each relationship including a 
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first participant and a second participant. 

18. The database of claim 13 wherein the program 
entity type conprisas a rule entity type and 
wherein the process to program relationship 
type comprises a process to male 
relationship "^pe. 

19. The database of claim 18, wherein the 
information comprises: 



a process instwce; 

one or more rule insteuices; 

one or more process to rule 
relationship instances, each such 
relationship instance relating 
each rule inst£mce to the process 
instance; 

one or more workstation instances; 
emd 



one or more workstation to process 
relationship instances, each such 
relationship instance relating 
each workstation instance to the 
process instance. 

20. The database of claim 19, wherein the 

program entity type further comprises a 
component entity type and wherein the 
program to program relationship type further 
comprises a rule to component relationship 
type and wherein the information further 
comprises : 
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one or more component instances; 
and 

one or more rule to component 
relationship instances, each such 
relationship instance relating 
each component instance to a rule 
instance • 

21 • The database of claim 19, wherein the 

program entity type further comprises a 
window entity type and wherein the program 
to program relationship type further 
comprises a rule to window relationship type 
and wherein the information further 
comprises: 

one or more window instances; and 

one or more window to rule 
relationship instances, each such 
relationship instance relating 
each window instance to a rule 
instance • 
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